在昨天我們認識了
軟體開發方法論的大致流程
規劃、開發、測試、部署、運營、維護和最終淘汰(或迭代)

那麼被很多人所述說的瀑布式是什麼呢?

其實就是順著昨天所說的流程這樣一步步的下來，
典型來說是定義、設計、編碼、測試、部署和維護，
可為什麼總會在面試或實際作業，
許多人把他視為一種落後不好的開發法呢?

最主要的原因就是，
很多時候沒有辦法明確的接續在上一階段完成，
這樣循序很明確沒錯，
但需要需求跟目標是明確的。

當然也有很多人推進許多改進，但這邊就直接述說結論。

我們都知道問題是出在瀑布模式最大的問題是，難以變化。

那這個難以變化是因為什麼呢?

每一階段的工作都在前一階段完成後才開始。
這代表需要一個階段完成並進入下一個階段，就不會返回前一階段進行修改或調整。

所以很明確的知道最大的元凶是這個，
那麼就有許多前輩來進行改善，
其中最重要的就是迭代。

那麼首先來認識迭代（Iteration）
是什麼

確定目標：在每個迭代開始之前，團隊需要明確確定目標和優先事項。這可以是添加新功能、修復錯誤、優化性能等等。確定目標時應該考慮項目的需求和客戶的期望。
規劃迭代：一旦確定了目標，就需要規劃迭代的工作。這包括確定迭代的時間範圍、分配資源、制定任務和設計實現目標的計劃。
實施工作：在每個迭代中，團隊開始進行實際的工作，包括編碼、設計、測試等。迭代通常有一個相對較短的時間範圍，例如2至4週，以確保快速交付結果。
測試和評估：在每個迭代的結尾，開發團隊會進行測試，確保產品滿足質量標準並符合需求。同時，團隊會評估達成的目標，以確保它們符合預期。
回饋和修正：根據測試和評估的結果，團隊會收集回饋信息並進行必要的修正。這可能包括修復錯誤、調整功能或重新設計部分系統。
重複迭代：一個迭代完成後，團隊可以開始下一個迭代，根據之前的經驗和反饋不斷改進產品。這個過程可以持續多個迭代，直到達到整體目標。
交付：在某個迭代中，團隊可能達到了足夠的功能或品質，可以交付給客戶或部署到生產環境中。

可以看到最主要的要點就是充滿彈性，
從一開始先確立一個大致的目標，
這裡就會有可以調整的餘地，
並且在最後交付的時候，
是可以在中途的某個迭代（Iteration）進行部屬。

那麼介紹先說到這，就稍微提一下，很多人都有提過的相關問題，
並且也時常有一些朦朧的部分。

有一部分的人會把大專案切成小專案，
並且分階段部屬，
這個動作視為迭代。

確實說的沒錯，
大專案如果切的夠細，
切到小專案能在相對較短的時間完成，
那麼看起來似乎跟迭代沒有區別。

但要注意如果切的不夠細，
剛好專案又是使用迭代，
那麼就會子專案底下又有迭代。

為什麼呢?
明明切成細的狀況下，
感覺沒區別，
但在這個情境下會有差異呢?

這是因為定義的目的不同，
這個例子是很典型的滑坡謬論。

舉個相似的例子，
一隻雞跟四分之一頭牛能提供相同的熱量
就說四分之一頭牛就是一頭雞，
這怎麼想都不對。

那麼到這邊，
我們都很清楚迭代是一個開發方法論，

那麼就只剩下
將大專案拆成子專案與分階段上線，
這一塊可以拆成兩部分，
大專案拆成子專案會是一種專案管理策略，
而分階段上線是一種部屬策略。

所以還請務必注意一下，
很多時候會遇到這種把有雷同的事情混為一談的狀況發生，
當然，
如果我有這種混淆的狀況，
還請拜託各位提出指正。